Programming Amazon Web Services by James Murty

Author:James Murty [James Murty]
Language: eng
Format: epub
Tags: COMPUTERS / Online Services / General
ISBN: 9780596551797
Publisher: O'Reilly Media
Published: 2009-02-08T16:00:00+00:00

Note

As long as the threads are in the sleep or run state, all is well. If any of the threads is in the dead state, it means that a receiver has crashed or been halted.

With the simulator running and waiting to receive messages, we can move over to the message sending console and send some new messages to the sqssim queue. To help the simulation run quickly, we will change the visibility timeout of the queue to 10 seconds.

irbm> sqs.set_queue_attributes(queue_url, 10, 'VisibilityTimeout') irbm> sqs.get_queue_attributes(queue_url) => {"ApproximateNumberOfMessages"=>0, "VisibilityTimeout"=>10}

Now that the queue is ready, we can send some test messages from our message-sending console. We will start with only a few, perhaps 20 to begin with. The content of each message will include a processing/sleep time value of five seconds, followed by a comma, then a brief note describing which message number this is in the series.

irbm> ptime = 5 irbm> 20.times {|i| sqs.send_message(queue_url, "#{ptime}, Message #{i}")}

As soon as we run these commands and the messages are sent, we can move back to the Simulator console to see notification log statements showing that the messages are being received and processed. These statements will look something like the following:

irbs> B1.1: received @Wed Sep 05 12:44:19 +1000 2007: '5, Message 1 - Event count: 1 B1.0: received @Wed Sep 05 12:44:20 +1000 2007: '5, Message 0 - Event count: 1 B1.1: deleted @Wed Sep 05 12:44:26 +1000 2007: '5, Message 1 - Event count: 2 B1.0: deleted @Wed Sep 05 12:44:26 +1000 2007: '5, Message 0 - Event count: 2

The log shows that there are two Receiver instances operating, identified as “B1.0” and “B1.1,” and that both are receiving and processing messages at the same time. The timestamp values printed in the log should show that the time taken to receive a message, process it, and delete it is slightly longer than five seconds.

We can check on the simulator’s progress in two ways. One is to retrieve the approximate number of messages remaining in the queue using the method get_queue_attributes in the message sending console:

irbm> sqs.get_queue_attributes(queue_url) => {"ApproximateNumberOfMessages"=>7, "VisibilityTimeout"=>10}

Alternatively, we can check the size of the event history hash stored in the Simulator class from the Simulator console. The history hash size will only give an indication of how many messages have been received, not how many of those have also been processed and deleted; but it serves as a decent estimate in this case.

irbs> perfect_sim.event_history.size => 4

Once all the queue’s messages have been processed, stop the simulator’s Receiver instances and confirm that all its threads are dead.

irbs> perfect_sim.stop_receivers irbs> perfect_sim.threads => [#<Thread:0x12aa098 dead>, #<Thread:0x12a50d4 dead>]

It is now time to analyze the message flow that was recorded during the simulation. To do this we will use the print_history method to display a summary of the interesting messages. However, if we run this method with no parameters, there will be nothing to display because, in our perfect simulated world, nothing interesting happened to any of the messages. Every message was received, processed, and deleted without errors or redeliveries.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.